Independent Reconciliations: Three Steps to Maintaining the Integrity of Your ERP

This fundamental question is misunderstood. We perform the act of reconciling to ensure the transactional data in our ERP agrees to data from a third party source. Bank transactions in the ERP, for example, are compared to an independent bank statement on a line by line basis. We then review the reconciling items such as deposits in transit, outstanding checks or interest income to ensure reasonableness and accuracy.

While bank accounts are the most common form of reconciliation, to truly “close the books” we need to reconcile our entire trial balance. This ensures the integrity of the ERP data and prepares us for the audit season.

When contemplating the rest of the trial balance, we find many subledgers being used to record entries to the general ledger, which provides automation. With that, there is a belief in the accounting world that subledgers are perfect – everything is properly recorded and there is no way there could be any reconciling items.

I’m here to tell you that a subledger to general ledger reconciliation just doesn’t cut it. Why?

Integrations with external sources aren’t perfect. When I was an auditor, I had this unfortunate belief that API’s are perfect and software integrations are accurate. In fact, I remember auditing IT integration points and we’d do a “test of one.”

If that single integration point passed the test, we would assume ALL data flowed perfectly. After moving into the corporate accounting world and then founding FloQast, I’ve come to learn that integration points are far from perfect and this testing methodology was laughable. ERP’s are just too complicated and have so many nuances across companies that it is very easy for something to fall through the cracks. Subledgers aren’t perfect.

Similar to the point above, subledgers don’t always feed into the general ledger perfectly for the same reasons – most companies have their ERP customized, and maintaining the integrity across every field requirement presents huge risks. When I was a corporate accountant, I was constantly reconciling our deferred revenue schedule against our subledger, and it took forever. Why? I had to deal with top-side adjustments, audit adjustments and custom field requirements on sales orders.

I found myself pouring through multiple sources of data and running many reports to figure this out every month, which was a huge risk from an audit perspective. We are not addressing two fundamental audit assertions – completeness and existence. Put simply, the only way to ensure completeness and existence is to have that data validated by a third party data source. When I was in accounting, we got past this by performing two reconciliations for deferred revenue.

I would first reconcile all new sales orders against the data in Salesforce to ensure completeness, existence and accuracy. I would then record all of my revenue entries and reconcile our deferred revenue by customer report against the general ledger. Once again, I found myself pulling data from multiple sources, cobbling together a reconciliation, and creating significant audit risk.

How should we reconcile?

In summary, the reconciliation is testing the validation of your ERP data. In the same way that audits are required to remain independent, reconciliations have to be independent. This is the only way to ensure all data posted to your ERP – whether entered manually or through an integration – is correct.

The validity of this data should be tested and ensured by an independent party, such as a human being or account reconciliation software. Solutions independent from the ERP all take an independent approach to ingesting data and testing the accuracy. By leveraging automation technologies, accounting teams can easily validate simple transactional data and focus their time on any anomalies that may have been incorrectly captured by the ERP (existence and accuracy) or not captured at all (completeness).

=========

Mike Whitmire is CEO of FloQast.